[Bug] Prevent hard process exit on Ctrl+C if an onCancel callback is passed to spinner#587
[Bug] Prevent hard process exit on Ctrl+C if an onCancel callback is passed to spinner#587kajoseph wants to merge 2 commits into
Conversation
commit: |
|
this feels like a workaround. i'll have a deeper think about it soon but i don't think we should be introducing conditional logic here. i think if we're going to do anything, we should just have an but it needs some thought first |
|
Honestly, I would prefer the process.exit call be removed entirely as it feels kind of reckless/sloppy programming-wise, but that's functionally a breaking change for users that rely on it (though I personally was relying on the spinner returning control back to the program - did this behavior change between alpha and 1.5? I digress). I can test |
2 participants
What does this PR do?
With the spinner running,
Ctrl+Chard-exits the node process with a buriedprocess.exit(0)as noted by @43081j here. This short-circuits the spinner stop cycle which prevents theonCancelcallback from running and also potentially leaves dangling connections to other services (e.g. a database).This PR changes the behavior slightly so that an
onCancelcallback will prevent the cancellation cycle from callingprocess.exit()and instead return control back to the program so that it can cleanly teardown connections or otherwise proceed as desired. This modified behavior is more in-line with the rest of the prompts in that aCtrl+Creturns control back to the program instead of treating it as a SIGINT.Closes #573
Type of change
Checklist
pnpm testpasses (or targeted tests for my change)pnpm formathas been runAI-generated code disclosure
* only the added test cases were generated with AI as I'm not as familiar with this test harness. Suggest verifying that it's testing properly.